IBIS Macromodel Task Group Meeting date: 01 October 2024 Members (asterisk for those attending): Achronix Semiconductor: Hansel Dsilva Altair: * Junesang Lee Amazon: John Yan ANSYS: * Curtis Clark * Wei-hsing Huang Aurora System: * Dian Yang Raj Raghuram Cadence Design Systems: * Ambrish Varma * Jared James Dassault Systemes: Longfei Bai Google: Hanfeng Wang GaWon Kim Intel: * Michael Mirmak [Kinger Cai] Chi-te Chen Liwei Zhao Alaeddin Aydiner Sai Zhou Keysight Technologies: Fangyi Rao Majid Ahadi Dolatsara Stephen Slater Ming Yan Rui Yang Marvell: Steve Parker Mathworks (SiSoft): * Walter Katz Graham Kus Micron Technology: Justin Butterfield Missouri S&T: * Chulsoon Hwang * Yifan Ding Zhiping Yang Rivos: Yansheng Wang SAE ITC: Michael McNair Samsung: Jun-Bae Kim Siemens EDA (Mentor): * Arpad Muranyi * Randy Wolff Signal Edge Solutions Benjamin Dannan Teraspeed Labs: [Bob Ross] Zuken USA: Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: Yifan: Further investigate the feasibility of using the plateau test to decide whether BIRD220.1 is applicable for a given device model. - Done. Yifan said she had an update to present. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the September 24th meeting. Michael moved to approve the minutes. Ambrish seconded the motion. There were no objections. -------------- New Discussion: BIRD220.1 update: Yifan reported on her continued investigation into whether looking for plateaus in the rising/falling edges of output transitions is a suitable test for the validity of the BIRD220.1 approach. She had previously demonstrated that the presence of a plateau in the edge when driving into a V_fixture of Vdd/2 was sufficient to indicate that BIRD220.1 was not applicable to the device, as it indicated the presence of separate pre-drivers for the pullup and pulldown stages. She then turned to determining whether the absence of the plateaus was sufficient to indicate that BIRD220.1 was applicable. Yifan showed a demo driver model including separate pre-driver stages. She had tuned the sizes of the NAND and NOR gates so that no plateau was seen when driving 50 Ohms to V_fixture = 0. She then swept V_fixture and demonstrated that no plateaus were seen in any of the rising edges. However, when she introduced noise on the pre-driver power rail, the PSIJ values were different for the pullup and pulldown pre-driver stages, and consequently the PSIJ value at the output was different than either of them and highly dependent upon the load. Yifan concluded that BIRD220.1 could not be applied to a device with separate pre-driver stages, even if they were synchronized to minimize skew between them. While a model maker could derive an equivalent PSIJ value for the device into a particular load, it would likely only be valid for that particular load. One possibility would be to provide the associated load along with the PSIJ value, as the model maker may know what the expected load conditions are. Arpad asked whether adding a PSIJ subparameter to the rising and falling waveform keywords would help. The waveform keywords already contain subparameters describing the load associated with each waveform. Yifan agreed that doing so would provide more information, but she asked how it would be utilized in simulation if the buffer is not aware of its real-time load. Arpad said he was wondering whether there was a reliable way for model makers to know whether BIRD220.1 was valid for their device, and he asked where we should go from here with this BIRD. Chulsoon said he and Yifan had discussed the issue at length. He suggested that they would proceed with the known limitation that BIRD220.1 can only be applied to devices with a single common pre-driver stage. Yifan said she would create a new draft of BIRD220.1 with additional sentences describing the limitations of the technique. Ts4file and [Ramp]: The group continued the previous discussions, and Michael focused on the table Walter had created enumerating the combinations of I-V, V-t, Ts4file, and External Model and their interactions with [Ramp] (sent to ATM prior to the meeting). Arpad noted that the [Ramp] dV vs. I-V check was missing. Walter agreed and said he would add another column. Walter said [Ramp] is used for time stepping when doing a time domain simulation, or for a fast crosstalk scan. He said it is only used to generate K(t) tables in the case where a model has I-V tables but no V-t waveforms. The parser currently only checks dV vs. I-V data, if I-V data exists. Ambrish said that [Ramp] may be syntactically required even when Ts4file is used, but it is not technically necessary. He said we should make it clear that [Ramp]'s only purpose is a first-order estimate of switching behavior in the Ts4file case. He suggested we use the same language used in the [External Model] case. Walter agreed. Michael noted that the table indicates where parser cross checks of [Ramp] data with other keywords' data are missing. He said the key question remains, what do we want to do for changing/defining parser requirements for checking [Ramp] vs. the newer replacement parameters/keywords (Ts4file, External Model)? Ambrish said the impetus for this whole discussion had been problems Michael encountered with a Ts4file model, and the parser's confusing checks of [Ramp] vs. I-V data in that case. He said the original intention when Ts4file was introduced was that if Ts4file is in the .ami file, then it replaces (is used instead of) the legacy modeling information in the .ibs file entirely. Arpad said that if we state that Ts4file is for AMI purposes only, then we have to allow the model to contain information to be used in non-AMI simulations. Ambrish said you could simply wrap your Touchstone file in a subcircuit and use [External Model] in that case, as the Ts4file section recommends use of [External Model] for providing equivalent behavior for non-AMI simulations. Arpad said one limitation of that approach is that Ts4file 4-port data models aren't useful for power integrity simulations. Walter said it's perfectly fine for a tool to use the Ts4file information in a time domain simulation, and the syntactically required [Ramp] is then useful as first-order time stepping information. Ambrish said that this violates the original spirit of the Ts4file parameter's usage, and if we want to use it for all simulation types then it should be in the .ibs file, not the .ami file. Michael said we need to decide if we should continue to require [Ramp] even in the presence of the new replacement keywords, or if we should relax the requirement that [Ramp] be provided. He asked EDA vendors to consider, what's the worst that will happen if [Ramp] is completely bogus? If there are newer replacement keywords provided, should [Ramp] be optional? If we continue to maintain the [Ramp] requirement, we should add the missing parser checks wherever possible. He said we all agree that checking [External Model] vs. [Ramp] is beyond the scope of the parser. However, checks against all legacy keywords, and even Ts4file, are theoretically things the parser could do. Arpad asked whether we should have the parser check Ts4file vs. [Ramp] and the I-V and V-t data. Ambrish said he did not think so. He said for Ts4file it is made abundantly clear that the legacy keyword data should not be used. Arpad said he didn't disagree with that statement, but we had run into trouble with early Ts4file models in which [Ramp] dt values had been set extremely low because the model maker mistakenly thought [Ramp] was providing a stimulus description. Michael noted that the parser already checks and complains if certain values are too large or too small according to some pre-defined sanity check values. For example, the parser complains about very large values in I-V tables or large values of C_comp. He said we might introduce a check against a pre-defined threshold for dt. Randy said that a hard low-limit sanity check might work, but the parser can't test anything below that value. Michael suggested a message such as, "The Ramp dt seems too small. It is intended to describe the output's ramp rate". The group noted that no one knew exactly where the existing arbitrary thresholds had come from, perhaps the IBIS cookbook discussions. Michael said if we remove the requirement for [Ramp] when Ts4file exists, then we don't have to worry about checking it. Walter said we should keep the requirement and add the same "first-order" language used in [External Model]. Ambrish said that [Ramp] is only "needed" when no V-t waveforms are provided. We merely kept [Ramp] around in the early days for tools that didn't yet support V-t waveforms. Walter asked what problems occur if we just leave things alone. He said we can add language saying that the parser doesn't check for consistency in all cases. Michael said the problem is the confusion caused by highly inconsistent crosschecking. Michael said that if we want to be consistent, we could either go with Ambrish's approach and make [Ramp] optional and stop checking it at all when Ts4file or [External Model] are present, or we can keep the [Ramp] requirement and be better about the crosschecking. Arpad said this went back to his previous questions about whether we should introduce the additional crosschecks the parser isn't currently providing. He said he would prefer to see all the reasonable crosschecking done. Randy said that if we only check dV, and we don't typically use dV, what's the point? Walter said he had no objection to adding dV and dt checks vs I-V and V-t data. Randy said we might need to add more info to [Ramp] to make all crosschecks against all waveforms possible. Walter said even crosschecking against Ts4file wouldn't be difficult. Michael noted that some freeware might already have this implemented. Michael took an AR to reach out to one developer to see if they'd be willing and able to provide code for this check. Ambrish expressed concern that this is only getting complicated because we've deviated from the original targeted approach for Ts4file, and we're now envisioning a single [Model] containing all of these various keywords. - Michael: Motion to adjourn. - Ambrish: Second. - Arpad: Thank you all for joining. New ARs: Yifan: Draft a new version of BIRD220.1 including language describing the limitations of the approach. Michael: Check to see if see if Ts4file cross checking code could be donated for use by the ibischk parser. ------------- Next meeting: 08 October 2024 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives